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Abstract 

The Internet has become a critical communication infrastruc¬ 
ture for citizens to organize protests and express dissatisfaction 
with their governments. This fact has not gone unnoticed, with 
governments clamping down on this medium via censorship, 
and circumvention researchers working to stay one step ahead. 

In this paper, we explore a promising new avenue for covert 
channels: real-time strategy video games. Video games have 
two key features that make them attractive cover protocols for 
censorship circumvention. First, due to the popularity of gam¬ 
ing platforms such as Steam, there are a lot of different video 
games, each with their own protocols and server infrastructure. 
Users of video-game-based censorship-circumvention tools can 
therefore diversify across many games, making it difficult for 
the censor to respond by simply blocking a single cover pro¬ 
tocol. Second, games in the same genre have many common 
features and concepts. As a result, the same covert channel 
framework can be easily adapted to work with many different 
games. This means that circumvention tool developers can stay 
ahead of the censor by creating a diverse set of tools and by 
quickly adapting to blockades created by the censor. 

We demonstrate the feasibility of this approach by imple¬ 
menting our coding scheme over two real-time strategy games 
(including a very popular closed-source game). We evaluate 
the security of our system prototype - Castle- by quantifying 
its resilience to a censor-adversary, its similarity to real game 
traffic, and its ability to avoid common pitfalls in covert channel 
design. We use our prototype to demonstrate that our approach 
can provide throughput which is amenable to transfer of tex¬ 
tual data, such at e-mail, SMS messages, and tweets, which are 
commonly used to organize political actions. 

1. Introduction 

The Internet has become a critical communication infrastruc¬ 
ture for citizens to obtain accurate information, organize polit¬ 
ical actions [1], and express dissatisfaction with their govern¬ 
ments [2]. This fact has not gone unnoticed, with governments 
clamping down on this medium via censorship [3-5], surveil¬ 
lance [6] and even large-scale Internet take downs [7-9]. The 
situation is only getting worse, with Freedom House reporting 
36 of the 65 countries they survey experiencing decreasing lev¬ 
els of Internet freedom between 2013 and 2014 [10]. 

Researchers have responded by proposing several look-like- 


something censorship circumvention tools, which aim to dis¬ 
guise covert traffic as another protocol to evade detection by 
censors. This can take two forms: either mimicking the cover 
protocol using an independent implementation, as in Skype- 
Morph [11] and StegoTorus [12], or encoding data for transmis¬ 
sion via an off-the-shelf implementation of the cover protocol, 
as in FreeWave [13]. 

This has created an arms race between censors and circum- 
ventors. Many censors now block Tor [14], so Tor has intro¬ 
duced support for “pluggable transports”, i.e. plugins that em¬ 
bed Tor traffic in a cover protocol. There are currently six plug¬ 
gable transports deployed in the Tor Browser Bundle [15]. Cen¬ 
sors have already begun blocking some of these transports [16], 
and some censors have gone so far as to block entire content- 
distribution networks that are used by some circumvention sys¬ 
tems [17]. 

Furthermore, recent work has shown that care must be taken 
when designing and implementing a look-like-something covert 
channel. For example, Houmansadr et al. showed that, when a 
covert channel re-implements its cover protocol, the copy is un¬ 
likely to be a perfect mimic of the original protocol, and a cen¬ 
sor can use the differences to recognize when a client is using 
the covert channel [18]. However, Geddes et al. demonstrate 
that even running the cover application is not enough to avoid 
detection by censors [19] - i.e., approaches like FreeWave may 
be detected via discrepancies between the application’s regular 
behavior and its behavior when being used as a covert channel. 
They classify these discrepancies into three categories: (1) ar¬ 
chitectural mismatches between communication patterns of the 
application when it is acting as a covert channel vs. regular 
operation, (2) channel mismatches between reliability require¬ 
ments of the application and the covert traffic and (3) content 
mismatches where the packet contents of the application dif¬ 
fer because of the covert traffic being sent in place of regular 
application traffic. 

In light of this state of affairs, this paper argues that video 
games have several features that make them an attractive target 
for covert channel development. 

There are many games available, enabling circumven¬ 
tion tool developers to create a diverse set of circumvention 
tools. The number of RTS games has grown rapidly in the last 
few years, as shown in Figure 1. This growth has been driven 
in part by the democratization of game publishing, as embodied 
in game distribution platforms such as Steam [20]. Each game 



o 



fC 


Figure 1: Growth of the real-time strategy game video-game 
genre from 2010 to 2014. 


uses its own network protocol and infrastructure, so the censor 
cannot simply block all games using a single rule. Censorship 
circumventors can use this large body of games to avoid a cen¬ 
sor’s attempt to block any particular game. 

Video games share common elements, making it possible 
to use a single framework across many games. For exam¬ 
ple, most Real-Time Strategy (RTS) games have the notions of 
buildings, units, and rally points, and censorship circumvention 
tools that encode information by interacting with these objects 
can be easily ported from one RTS game to another. Many 
games also feature replay logs and similar user interfaces, en¬ 
abling covert channel frameworks that are only loosely coupled 
to any particular game. 

Circumvention tools can re-use off-the-shelf game imple¬ 
mentations to avoid the pitfalls identified by Houmansadr 

et al. Since games have features that make it relatively easy 
to automate interaction with the off-the-shelf implementation, 
circumvention tool developers do not need to re-implement the 
game (or its network protocol), ensuring that the censorship 
tool uses a faithful implementation of the game protocol. 

Games provide good architectural, channel, and content 
matches to censorship circumvention tools for textual com¬ 
munications. Many game support both peer-to-peer and server- 
based gaming sessions, so they can adapt to whichever is better 
for the circumvention tool. Games must maintain synchronized 
state, so they are loss sensitive, avoiding the pitfalls that Ged- 
des et al. found in FreeWave [13]. Finally, games send frequent 
small packets, matching textual communications. 

Games have built-in security features that can support 
secure covert channels. For example, most games include en¬ 
cryption and authentication to prevent cheating. Many games 
also support password-protected sessions, which can prevent 
application-level attacks in which the censor attempts to iden¬ 
tify covert channels by joining the game. 

By lowering the development cost of creating new covert 
channels, video games may create an asymmetry that censor¬ 
ship circumventors can use to win the arms race against cen¬ 
sors. Censors can respond to look-like-something circumven¬ 
tion tools by blocking the cover protocol entirely or attempt¬ 
ing to distinguish legitimate uses of the protocol from uses by 
the covert channel. If developing such blocking tools is time 
consuming, but the circumvention tool developers can quickly 
move their tool to a new cover protocol, then there will almost 
always be effective circumvention tools available for end users. 

However, we must answer several questions to understand 
the feasability of using video games for covert channels: 

• Can video games support good covert channel bandwidth? 


• Can we encode data in the video game so that the censor 
cannot distinguish regular game play from covert chan¬ 
nel sessions? 

• Can we develop a covert channel framework that can be 
quickly adapted to new games? 

To answer these questions, we have built Castle, a prototype 
video-game-based covert-channel framework. Castle encodes 
data as player actions in an RTS game. Castle uses desktop- 
automation software to execute these actions in the game. The 
video game software transmits these moves to the other players 
in the same gaming session, who then decode the message and 
send replies in the same way. 

Castle can be easily adapted to new RTS games. Our current 
prototype supports two such games: “0-A.D.” [21] and an ex¬ 
tremely popular (over three million copies sold) closed-source 
game that we will refer to as “Aeons”. It took a single under¬ 
grad less than six hours to port Castle from 0-A.D. to Aeons. 

Castle is easy to port to new RTS games for two reasons. 
First, Castle uses only features, such as buildings, units, and 
“rally points”, that are nearly universal to RTS Games. Thus 
the high-level architecture and encoding scheme can be re-used 
across games. Second, Castle is only loosely coupled to game 
internals. For example, Castle uses desktop-automation soft¬ 
ware to execute game actions through the game’s standard graph¬ 
ical user interface. Similarly, the Castle decoder reads actions 
from the game’s replay log, which means that it does not need 
to understand the game’s network protocol or other internals. 
For many games, development is made event easier by the ready 
availability of code to parse their replay logs. 

Castle offers good bandwidth for text-based communications. 
Our current prototype provides between 50 and 200 B/s of band¬ 
width, depending on configuration parameters. Castle has about 
lOOx more bandwidth than other proposed game-based covert 
channels [22-24] * . With some game-specific tuning, the Aeons 
version can deliver over 400 B/s. Even 50 B/s is sufficient for 
email, SMS messages, and tweets, which are widely used orga¬ 
nizational tools among political activists. There are also several 
ways to potentially increase Castle’s bandwidth (see Section 8 
for details). 

Castle’s design makes it resilient to most classes of attacks. 
Since Castle uses the underlying game to transmit data, an at¬ 
tacker cannot use simple IP- or port-based blocking to block 
Castle without blocking the game entirely. When used with 
games that encrypt and authenticate their traffic, an attacker 
cannot use deep packet inspection to distinguish Castle traffic 
from regular game traffic. Encryption and authentication also 
preclude simple packet injection or manipulation attacks. Since 
games use network communication to synchronize their state, 
they are loss sensitive, unlike some VoIP protocols. Thus Castle 
cannot be distinguished from regular gaming sessions through 
selective packet delay or dropping attacks. Einally, when used 
with password-protected gaming sessions, Castle is immune to 
application-level attacks, such as the censor attempting to join 
the same gaming session to observe the player’s in-game ac¬ 
tions. 

We evaluate Castle’s security against statistical traffic-analysis 
attacks by applying several previously published classifiers. We 

^Despite the similarity of their names and their common use of 
video games. Rook and Castle were developed independently 
and have quite different goals. See Section 8 for details. 















find that packet sizes and interpacket times of Castle’s traffic 
deviate from those of regular human-driven game play by the 
same amount that different human player’s traffic differ from 
eachother. We also find that the Liberatore [25], Hermann [26], 
and Shmatikov [27] classifiers cannot distinguish Castle traffic 
from regular game traffic with success much better than random 
guessing. 

Together, these results show that video games offer promise 
as a target for covert channel development and that video games 
may enable circumention tool developers to gain the upper hand 
in the arms race against censors. 

Paper outline. In Section 2, we present the adversary model 
that we consider in this paper. Section 3 provides some back¬ 
ground on real-time strategy games, details the properties that 
makes them favorable for use as cover protocols in covert chan¬ 
nels, and explains how Castle makes use of each of these for 
sending and receiving covert data. In Section 4, we provide de¬ 
tails on our publicly available implementation of Castle. Fol¬ 
lowing this, we describe our evaluation framework in Section 
5. In Sections 6 and 7, we present the results of Castle’s se¬ 
curity and performance evaluation, respectively. In Section 8, 
we discuss the impact that Castle makes on the currently on¬ 
going censor-developer arms race, modifications that may be 
made to Castle for additional throughput gains, and compare 
the primary design principles of Castle with it’s most similar 
counter-parts. Finally, in Section 9, we draw our conclusions 
and provide a link to a video demonstration of Castle. 

2. Adversary and Threat Model 

In this paper, we consider a network-level censor (e.g., an 
ISP) who is able to perform analysis over all traffic that it for¬ 
wards from or to clients within its network. It may also perform 
manipulations (e.g., dropping packets, injecting packets) of the 
network traffic via on-path or in-path middleboxes. The adver¬ 
sary may also take an active approach and probe application 
endpoints or otherwise interact with the game. 

In this section, we overview the capabilities of the censor 
that we aim to evade using Castle. We describe the resilience 
of Castle to these adversary behaviors in Section 6. 

2.1 Network traffic attacks 

Passive analysis. We consider censors that are able to perform 
stateless and stateful passive analysis of traffic at line rate. In 
particular, the censor is able to perform the following passive 
analyses to detect the use of a circumvention tool: 

• IP and port filtering: The censor can observe the IP ad¬ 
dresses and port numbers of connections on their network 
(e.g., using standard tools like Netflow [28]). 

• Deep-packet inspection: The censor may look for specific 
patterns in packet headers and payloads (e.g., application 
payloads indicative of a specific game). 

• Flow-level analysis: The censor may perform statistical 
analyses of flow-level characteristics such as inter-packet 
times and packet sizes). 

The first two of these capabilities mean that the ISP can eas¬ 
ily detect flows related to the video game in general. For ex¬ 
ample, if the game uses a specific set of servers (IPs) or ports 
these flows may be easily identified. Similarly, game-specific 
application payloads can reveal game traffic to the ISP. The last 
property can reveal information about game behavior to the ISP 


(e.g., rate of play). A circumvention system must avoid perturb¬ 
ing these features to remain undetected and unblocked. 

Active manipulations. In order to detect and/or disrupt the 
use of censorship circumvention tools, censors may perform a 
variety of active manipulations on suspicious connections that 
transit its network. In particular, the censor may drop, insert, or 
delay packets. Additionally, they may also modify the packet 
contents and headers. The adversary may perform these ma¬ 
nipulations to observe the behavior of flow endpoints to dis¬ 
tinguish legitimate game traffic from the covert channel. They 
may also use these actions to block covert connections (e.g., 
sending TCP RST packets, or dropping traffic). 

2.2 Application layer attacks 

In the context of detecting look-like-something covert chan¬ 
nels, censors may take additional actions outside the scope of 
standard active and passive analysis. Specifically, they may in¬ 
teract with the application that the covert channel aims to hide 
within. They may join game servers and observe games in 
progress (i.e., who is playing with whom). They may observe 
properties of the games (e.g., map state, player move behav¬ 
iors) or join and interact with game players if the game is not 
password protected. 

Censor limitations. We impose some limitations on the 
computational capabilities of censors. While they have a large 
amount of computational resources, they are still unable to de¬ 
crypt encrypted communication channels and guess high en¬ 
tropy passwords. We also assume that the censor does not have 
a back door into the game or game servers. For example, we 
assume the censor is not able to break into the game servers 
(e.g. by exploiting a buffer overflow or other bug). We also 
assume that the operators of the game servers do not cooperate 
with the censor, e.g. they do not allow the censor to see other 
user’s private game state. 

3. The Castle Circumvention Scheme 

Castle aims to demonstrate that secure and low-bandwidth 
look-like-something defenses are possible via interactive chan¬ 
nels such as real-time strategy video-games. In this section, we 
provide a background on real-time strategy games and high¬ 
light key properties of these games that enable Castle to create 
covert channels that generalize to the entire genre. We then 
describe how Castle encodes, sends, and receives data. 

3.1 Real-time strategy games 

Real-time strategy games are a genre of video games that 
center around the idea of empire-building. Typically, the goal 
is for a player to assert control over enemy territory through a 
combination of military conquest and economic maneuvering. 
Below we highlight commands and features that are common 
to a large majority of real-time strategy games (Table 1). 

• Units: Real-time strategy games allow players to create 
and train a large number of units (e.g., human characters, 
livestock, machinery). Units may perform many actions 
e.g., in 17 of the Top 20 best-selling real-time strategy games, 
a unit can be instructed to move to a location on the map by 
left- clicking it and then right clicking the destination loca¬ 
tion on the map. 

• Buildings: Players may construct a number of buildings 
over the course of a game. Buildings are required to train 



certain units and research new technologies. For instance, 
barracks may be required to train infantry. Some buildings 
produce new units of other types. In most real-time strat¬ 
egy games, unit-producing buildings can be assigned a rally 
point - i.e., a location on the map at which all units created 
by the building will assemble. This command is available 
in 17 of the Top 20 best-selling real-time strategy games. 

• Maps and map editors: Real-time strategy games are set 
in a landscape covered by plains, forests, mountains, and/or 
oceans. Most real-time strategy games allow users to create 
their own maps and modify existing maps for use within the 
game. Map editors released by the publisher or the mod- 
ding community are available for 17 of the Top 20 real-time 
strategy games. 

• Replay files: Players may be given the option to record all 
moves and commands issued by themselves and other play¬ 
ers in the game. This is used to replay or watch previously 
played video-games. When this option is enabled, the game 
writes, in real-time, all commands issued in the game to a 
replay log that may be in a proprietary format. Replay hie 
decoders are available for 11 of the Top 20 real-time strat¬ 
egy games. 

In addition to the above elements, many commercial real¬ 
time strategy games also possess the following networking and 
security properties that are advantageous for use as cover pro¬ 
tocols for covert channels. 

Network communications. For scalability reasons, real-time 
strategy games do not broadcast state information to all play¬ 
ers in the game. Instead, they pass commands issued by the 
players in hxed intervals (e.g., 100 ms). These commands are 
then simultaneously simulated in each game client. This al¬ 
lows clients to execute the game identically, while requiring 
little bandwidth [29]. As a consequence, any data encoded as 
an in-game command is received as such, by players at the other 
end. 

Additionally, while most real-time strategy games make use 
of UDP channels for command communication, reliability is 
implemented in the application layer. This makes many active 
traffic manipulation attacks described in previous work [19] in¬ 
effective. 

In terms of network architecture, real-time strategy games 
may take two forms, with players joining a common game hosted 
on a game server (e.g., servers hosted by game publishers such 
as Microsoft, Blizzard, Electronic Arts, etc.), or connecting di¬ 
rectly to each other in a peer-to-peer mode. Therefore, any 
covert channel system utilizing video games as a cover, can 
employ whichever is the dominant mode of operation and shift 
from one to the other if required, to evade censorship. 

Security considerations. Real-time strategy games often im¬ 
plement several security mechanisms in order to prevent cheat¬ 
ing in multi-player game sessions. These include encrypting 
and authenticating the communication channel that carries player 
commands, verifying the consistency of the game state with 
other clients in the game, and restricting access to game ses¬ 
sions via a password. 

These security mechanisms have several vital consequences 
for their use as covert channels. First, since the game command 
channel is encrypted, passive adversaries are unable to view 
commands issued by players in a game by simply observing 
network traffic. Second, the presence of authenticated channels 
and game-state verification algorithms prevents active attackers 


from using falsified game packets to interact with, or observe 
other clients on the game servers. 

Commonalities between real-time strategy games. Our pro¬ 
totype, Castle, leverages the common command structure, map 
design capabilities, and tools for decoding saved games and re¬ 
plays generated by real-time strategy games. A survey of real¬ 
time strategy games reveals that 11 of the top 20 best-selling 
games of all-time also include these features (Table 1). 


Feature 

Number of Games 

Common Comands (MOVE- 
UNITS or SET-RALLY-POINT) 

17 of 20 

Map Editors 

17 of 20 

Replay Decoding Tools 

11 of 20 


Table 1: Real-time strategy game features used by Castle and 
the number of games in the Top 20 best-sellers of all-time that 
possess them. [30] 

3.2 Building game-based covert channels 

straw-man approach. One may consider establishing covert 
communication channels via the in-game voice and text chat 
channels. However, this approach has several drawbacks. First, 
previous work shows that encoded data is easily distinguishable 
from human audio communication [18,19]. Furthermore, voice 
communication channels are fairly uncommon in the real-time 
strategy game genre. Second, while game data is encrypted, 
it is often the case that text communication channels are left 
unencrypted. Finally, while one may expect a fairly constant 
stream of human issued in-game commands in a real-time strat¬ 
egy game, it is rare to have long text or audio communication 
while playing the game. These factors allow covert channels 
built on these approaches to be either difficult to implement 
and extend, or to be trivially detected by an adversary, or both. 
The Castle approach. In order to create a covert channel 
mechanism that is general to the majority of games in the real¬ 
time strategy genre, Castle exploits two key properties. 

• Most real-time strategy games share a common set of ac¬ 
tions. Specifically, the ability to select buildings and assign 
a location where units created/trained in a building should 
go. This location is called a “rally point,” and we denote 
the command of setting the rally point for units created in 
a given building by SET-RALLY-POINT. Games also pro¬ 
vide the ability to move a selected unit to a given loca¬ 
tion (denoted by the MOVE command). Thus, any encod¬ 
ing that translates data into a combination of unit/building 
selections and these primitives will be general across most 
games in this class. 

• Most real-time strategy games provide a replay option which 
saves every players’ moves to disk (for later playback). 
Therefore, all in-game commands are written to disk where 
they can easily be read and decoded in real-time. 

Castle consists of two main components to send and receive 
data. These are illustrated in Figure 2. Sending is done by 
encoding data into game commands and then executing them 
within the game using desktop automation. The receiving pro¬ 
cess monitors the log of game commands and decodes this list 
to retrieve data sent via the system. 

Figure 3 overviews how the Castle system could be used to 
relay data from outside of a censored region to a client within 
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Figure 2: Overview of data flow for sending an receiving in 
Castle. Shaded components are implemented as part of Castle 
while the others use existing off-the-shelf software. 



Figure 3: Overview of how Castle can be used as a proxy for 
clients within censoring countries. A game client outside of 
the censoring region acts as a proxy between the game and the 
censored content (e.g., Web pages). 


the region. The client first installs Castle (e.g., as a browser 
extension). The Castle client then initiates a game through a 
game lobby (or directly with the client outside of the censoring 
region). The client in the censoring region can then encode and 
send data (e.g., Web requests) as game moves that can be de¬ 
coded by the client outside of the censoring region. The game 
client outside of the censoring region can then act as a proxy to 
retrieve censored content and send it via Castle to the client in 
the censoring region. 

3.3 Encoding data into game commands 

Castle relies on the ability of the player to select units and 
buildings and set rally points to encode data. A naive encoding 
may consider selecting each unit and directing it to a different 
point on the game map to encode a few bytes of information per 
unit. Flowever, in preliminary experiments, we observed that 
this approach resulted in a covert channel that could not match 
the properties of the original game traffic (moving 0(100s) of 
units to distinct locations is not a usual action for players). 

Encoding in Castle is accomplished, without inflating the 
amount of game data transferred, using the following scheme. 
First, the participants in Castle download a custom map (dis¬ 
tributed via game forums or stores such as Steam) which con¬ 
tains either n immobilized units (e.g., units placed in unit sized 
islands, within walls, etc.) or n unit producing buildings (e.g., 
barracks, stable, etc.). The Castle sending process then encodes 
data by selecting a subset of these n units and executing either 
a MOVE command in the case of units or SET-RALLY-POINT in 
the case of buildings. While we discuss the encoding in the 
context of units and the MOVE command, Castle is easily imple¬ 


mented using either primitive. 

Instead of using selection of each unit to represent a single 
bit sequence, which would result in log 2 (n) bits of data trans¬ 
ferred per command, we use a combinatorial scheme where we 
select k of the n units, to increase efficiency. Intuitively, the se¬ 
lection of k of n units results in different values or log 2 (j) 
bits that may be transferred per command. We use combinato¬ 
rial number systems [31] to convert log 2 (^) bits of data into a 
selection of k of the n units on the game screen. In preliminary 
experiments, we found that the selection of a constant number 
of units per command resulted in traffic which was more uni¬ 
form than regular game traffic. As a result, we adjusted our 
scheme to select between 0 and k units for encoding to increase 
variability of packet sizes. Section 6 provides a more in-depth 
view of how we evaluate our similarity to actual game traffic. 

In addition to selecting the set of units, we can also select a 
location for all k selected units to move to. Note that since we 
select a single location for k units (instead of k distinct loca¬ 
tions) this does not impact the data transfer size. Given a game 
map with m = x^ax x ymax potential locations we can addition¬ 
ally encode log 2 m additional bits of data in a given turn. 

Assuming a map with n units/buildings, a maximum of m = 
^max X ymax map locations, and a game which allows for a max¬ 
imum of k units/buildings to be selected simultaneously, the 
game-independent encoding of covert data into a MOVE or SET- 
RALLY-POINT command is done as shown in Algorithm 1. 


Algorithm 1 Algorithm for encoding covert data into game 
commands_ 

function ENCODE(data, k, n, m, Xmax) 
r-^{l,...,k} 

Zi READ(iiafa, log 2 (")) 
for i = 0 do 

if (') < zi then 
zi^zi- 

selected i— selected\\i 

end if 
end for 

Z2 READ(iiafa, log 2 m) 

( X , y ) i (Z2 mod Xmax 5 \_Z2 j^max\ ) 
return {selected, (x, y)} 

end function 

function READf/i/e, x) 

return next x bits from file in base 10. 

end function 


The combination of selecting between 0 and k units and set¬ 
ting the location to move to, results in an average of 




+ log 2 m 


bits transferred per command. 


As mentioned earlier, one may achieve higher data-rates by 
always selecting k units, however, this causes identically sized 
commands and thus affects the packet size distribution. 


3.4 Sending covert data 

Once the covert data is encoded into in-game commands, 
the sending process must actually execute the commands in or¬ 
der to communicate them to the receiver. One way to do this 
is to modify the game AI to issue commands as dictated by 
our encoder. However, this is non-trivial since most games are 
closed-source and viewing/modifying game code is not always 






































































an option. Even when source code is available, the overhead 
of understanding the game code and modifying the AI presents 
a non-trivial hurdle. Given our vision of adaptability to the 
large number of available real-time strategy games, we leverage 
off-the-shelf desktop automation to execute the encoded game 
commands. This opens the door to extending our approach to a 
much larger set of games than would otherwise be possible. 

Since the map used in Castle is custom made, the starting lo¬ 
cation of all units is known in advance. Further, since units and 
buildings are immobile, Castle is aware of their location at all 
times. The location of units on the game map, along with the 
list of commands to be executed is sufficient for Castle to au¬ 
tomatically generate a sequence of key-presses, left-clicks, and 
right-clicks to be made by the desktop automation tool. This 
sequence is then passed to the automation tool for execution. 

We note that, certain automation tools allow keystrokes and 
clicks to be sent to windows that are not currently in focus. 
This ensures that Castle does not detract from the user experi¬ 
ence by requiring the game window to be in focus during data 
transfer periods.Finally, since automation tools allow control 
over the speed of clicks and key-presses, Castle can be config¬ 
ured to either mimic human input speeds (lower clicks/second) 
or maximize throughput (higher clicks/second). We investigate 
the trade-off between these two variables in Sections 6 and 7. 

3.5 Receiving covert data 

Since the receiving game client does not have the same in¬ 
game screen as the sending client (due to each client having 
their camera focused on different map locations), directly ob¬ 
serving the commands made by the sending client via the screen 
output is prohibitively complex. Fortunately, most real-time 
strategy games maintain a real-time log of all commands issued 
in the game to enable replaying moves or saving game state. In 
Castle, the receiving process constantly monitors this log file 
for commands issued by other participants. These commands 
can then be decoded back into their original covert data via the 
decoding algorithm specified in Algorithm 2. 


Algorithm 2 Algorithm for obtaining covert data from game 

commands _ 

function DECODEfse/ecred, (x, y)) 
size •(— \selected\,zi = 0 
selected •«- SORT-DESCENDING(5e(ecred) 
for i G selected do 

Z1 ^ Z1 + {size—) 

end for 

Z2 ^ (yXVmar)+X 

return {base 2 (z\)\\base 2 (z 2 )) 

end fnnction 


This approach suffers from one minor drawback: replay logs 
for games from commercial studios are often stored in propri¬ 
etary and undocumented formats that vary from game to game. 
However, reverse engineering the format of the replay logs is 
made significantly easier since Castle only issues MOVE or SET- 
RALLY-POINT commands. Therefore, we only need to under¬ 
stand how these commands are stored in replay logs. This can 
be done by simple techniques - e.g., sending a unit to the exact 
same location multiple times allows us to obtain the byte code 
used to signify the MOVE command, sending a unit to two loca¬ 
tions in sequence (with each separated by a single pixel) allows 


us to obtain the bytes used to denote the (x, y) destination 
co-ordinates, etc. Further, for many popular real-time strategy 
games, these formats have already been reverse-engineered by 
the gaming/hacking community. 

4. Castle Prototype Implementation 

In this section, we describe our prototype implementation of 
Castle. We prototype on two games to illustrate the extensibil¬ 
ity of our approach. 

• 0 A.D.: An award-winning, free, open-source, and cross¬ 
platform real-time strategy game made available under the 
GPLv2+ license, by Wildfire Games. 

• Aeons: A best-selling (currently in the top 5 grossing real¬ 
time strategy games of all-time), closed-source, Windows- 
based real-time strategy game. 

Our prototype comprises of ~500 LOC and was coded in a 
combination of Python and AutoHotkey (desktop automation) 
[32] scripts. It includes the following components: 

Custom map: To test Castle, we created a custom game map 
for each of the two games. The map was comprised of n build¬ 
ings packed as tightly as possible to facilitate our selection- 
based encoding. 

For 0 A.D., we created a map with n = 1600 buildings on 
a single game screen, while for Aeons, we were only able to 
have n = 435 (owing to larger unit sizes). For both games, a 
region large enough to contain 16 bits of location data was left 
unoccupied. This is used to assign rally-point coordinates to 
the selected buildings. 

Since 0 A.D. stores maps in a simple and readable XML for¬ 
mat, the process of map creation was easily automated (via a 
Python script). This was not the case for Aeons which required 
manual generation of the map using the official GUI map ed¬ 
itor. We are currently exploring automation options for map 
creation in Aeons. 

Data encoding and decoding: Code for translating between 
covert data and in-game commands (and vice-versa) was writ¬ 
ten in under 200 lines of Python using the encoding and decod¬ 
ing described in Section 3.3. The output of the encoding code 
was a vector of buildings to be selected and a single (x, y) 
coordinate. 

Desktop automation: We used the open-source desktop au¬ 
tomation tool, AutoHotkey, to execute the series of commands 
determined by the encoding scheme. Since the locations of 
all buildings and units were known, selecting and command¬ 
ing those indicated by the encoding was straightforward. 
Reading recorded game data: We implemented code that 
monitored the log file of commands issued (maintained by the 
game), for both games. For 0 A.D., this information was al¬ 
ready made available in a simple to parse text file. In order 
to obtain this information for Aeons, the game replay file was 
parsed using tools made available by the gaming/hacking com¬ 
munity. The file was then scanned to obtain each command as 
a vector of selected buildings and an (x, y) coordinate. The 
commands were then decoded to retrieve the originally encoded 
covert data. 

Coordinate calibration: The isometric perspective of the 
game screen posed a challenge during the decoding process. 
Specifically, the presence of a viewing angle meant that a sender 
may have intended to move a unit to the screen coordinate (xj, 



Ys), but the game actually logged the command as an order to 
move the unit to the game coordinate (x^, jg), making this 
the command obtained by the receiver on decoding the move 
log. In order to avoid this problem, Castle goes through a one¬ 
time calibration process of mapping on-screen coordinates to 
coordinates as interpreted in the game. Note that the results of 
this calibration process can be shared across game clients that 
utilize the same in-game resolution. 

5. Evaluation Setup 

We evaluate Castle along two axes. First, in Section 6 we 
consider security of the Castle by quantifying its resilience to 
the censor-adversary described in Section 2 and its ability to 
avoid the mismatches highlighted by Geddes et al. [19]. We 
then study throughput of Castle using the encoding scheme as 
laid out in Section 3. We also consider the effect of minor 
game-specific improvements to Castle’s throughput. 

For the evaluation in Sections 6 and 7, we use our implemen¬ 
tation of Castle with a building-based map, using SET-RALLY- 
POINT commands.The evaluation was performed on Windows 
8.1 running AutoHotkey [32] for automation. The game was 
set up in direct connect mode - i.e., the two players were con¬ 
nected directly to each other via their IP address (rather than 
through the game lobby). Since both players were on the same 
(fast) university network, negligible effects of lag were experi¬ 
enced. 

Castle was used to transfer a randomly generated (via /dev/ 
urandom) 100KB binary file from one player to another. Net¬ 
work traffic generated by the game was captured using Raw- 
cap (a command-line raw socket packet sniffer for Windows) 
with additional processing done using tcpdump on Linux. 

We considered the impact of command rate {i.e., how long 
AutoHotkey waits between each command) and the impact of 
the maximum number of buildings selected (k) on the perfor¬ 
mance and security of Castle. For this we varied the command 
delays from 100 ms/command to 1000 ms/command. In the 
same vein, the number of selected buildings is varied from 25 
to 200. Additionally, to observe the impact of game-specific 
modifications, we evaluated the throughput of Castle over the 
closed-source Aeons, with and without any game-specific mod¬ 
ifications, in the same settings described above. 

In order to compare the traffic characteristics of Castle with 
characteristics of the standard game, we gathered network traces 
of regular 0 A.D. two-player games. These were also collected 
in a similar setting - i.e., with both players on the same univer¬ 
sity network and via direct connect. Ten traces were collected 
(one per game played). Each of the recorded games was be¬ 
tween 20 and 60 minutes long. 


6. Security Evaluation 

We now perform an evaluation of Castle against the network 
adversary described in Section 2. 

6.1 Resilience to network traffic attacks 

Passive analysis. We first consider attackers with the ability 
to perform IP and port filtering, deep-packet inspection, and 
simple flow-level statistical analysis at line rate. 

IP and port filtering: Since Castle actually uses an off-the- 
shelf implementation of the game application, the IP address 
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Figure 4: Kolmogorov-Smirnov (KS) statistic on the distribu¬ 
tions of packet sizes. The difference between Castle and the 
legitimate game flows is within the variance observed when 
comparing traffic between legitimate game flows. 
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and ports used by Castle are identical to that of the standard 
use of the game. This means that an adversary that triggers 
blocking based on the destination IP (e.g., the game server) or 
port number, will be forced to block all traffic to and from the 
game being used as the cover protocol. 

In the event that the censor is willing to block all connections 
to dedicated game servers (often hosted by game publishers - 
e.g.. Electronic Arts, Microsoft, Blizzard, etc.), clients may still 
utilize Castle in direct-connect mode, forcing the censor into a 
game of whack-a-mole with Castle proxies hosted outside their 
jurisdiction. Eurther, users may also easily migrate Castle to 
another real-time strategy game whose game servers are un¬ 
blocked. 

It is also worth noting that blocking game flows is not with¬ 
out costs to the censor, specifically with respect to political 
good will and PR internationally. Eor example, blocking all 
traffic for a given game, especially a popular game, may up¬ 
set citizens within their country and reflect poorly on Internet 
freedom within the censoring country [33-35]. 

Deep-packet inspection: When used with games that encrypt 
their communications, Castle is resistant to deep-packet inspec¬ 
tion, since the censor cannot decrypt the stream of moves being 
made. 

However, since Castle works by issuing only generic com¬ 
mands (e.g., MOVE and SET-RALLY-POINT), it can easily be 
detected by DPI boxes if the game communicates commands 
in plain-text. Eoitunately, most commercial real-time strategy 
games perform command channel encryption (e.g., all of the 
Top 10 best-selling real-time strategy games), making them re¬ 
silient to such censors. 

Flow-level statistical analysis: To quantify the resilience of 
Castle against flow-level attacks, several statistical tests and 
classifiers were employed. Eor each experiment, the Castle 
configuration parameters that control the command rate and the 
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within the variance observed when comparing traffic between 
legitimate game flows. 
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Figure 6: The performance of Castle in various configurations 
against website fingerprinting classifiers. 


maximum number of buildings selected in a command were 
varied between 0-1000 ms and 25-200 buildings, respectively. 

First, the Kolmogowv-Smimov (KS) statistic was used to 
compare the similarity of human-game-generated traffic and 
Castle-generated traffic. Figure 4 reflects the KS similarity 
statistic on the packet size distributions of human- and Castle¬ 
generated games and Figure 5 does the same for inter-packet 
times. We make two observations from these plots: (1) There 
is a high variation in the flow-level features of legitimate (i.e., 
human-game-generated) traffic. We hypothesize that this is be¬ 
cause the traffic generated by the real-time strategy game is 
strongly dependent on many parameters such as map and sce¬ 
nario type, strategies employed, and number of players. (2) 
Castle in many configurations, generates traffic that is well within 
this variance. We find that while restricting the maximum num¬ 
ber of units per command to under 50 and the command rate to 
around 1 command/second, Castle generates traffic that is as 
most similar to traffic generated by legitimate games. 

Next, Castle was evaluated against several website and traffic 
fingerprinting classifiers. The goal was to evaluate the accuracy 
of classifiers, built for flow-level analysis, in distinguishing be¬ 
tween Castle-generated and human-generated traffic. 

First, each network capture was split into (20) one minute 
long chunks. For each experiment, classifiers were given 20 
chunks of Castle-generated traffic at a specific configuration 
and 20 randomly selected human-game-generated chunks. Ten¬ 
fold cross validation was employed for splitting chunks into 
training and testing sets. 

Since, in our experiments, Castle was used for the purpose 
of file transfer, all traffic generated by it was in a single di¬ 
rection. This makes it trivially detectable by some fingerprint¬ 
ing classifiers which are heavily reliant on burst and direction 
features (e.g., k-NN [36], the Panchenko classifier [37] and 
OSAD [38]). We note that in a real deployment this directional¬ 


ity would not be an issue as there would be requests/responses 
from both sides. 

Due to the directionality of traffic, website fingerprinting 
classifiers that ignored directional information were used. These 
included the Liberatore classifier [25], the Flerrmann classi¬ 
fier [26], and an inter-packet timing classifier [27]. All classi¬ 
fier implementations were obtained from Wang’s open-source 
classifier archive [39]. The results of these experiments are il¬ 
lustrated in Figure 6. In general, the results indicate that Castle 
performs very well against packet size and timing classifiers, 
with only the Herrmann classifier achieving an accuracy of over 
60% against multiple configurations of Castle. This is not much 
better than random guessing. 

Active traffic manipulations. In the face of active traffic ma¬ 
nipulation attacks, such as probing, packet injection, and modi¬ 
fication, Castle implemented over most commercial games faces 
little threat. 

Packet injection. If Castle is implemented over a real-time 
strategy game with an encrypted and authenticated command 
channel (e.g., any of the Top 10 best-sellers of all time), any 
packets injected by an unauthenticated source are dropped by 
the game-server. As a result, a probing adversary learns nothing 
about the Castle games running on the server. 

Packet modifications. Most packet modification attacks are 
prevented by the presence of encrypted and authenticated in¬ 
game channels. Additionally, since Castle does not require any 
changes to the game or the hosting server, such attacks will al¬ 
ways elicit the same response from both, legitimate game play¬ 
ers and Castle users. 

Packet dropping and delaying. Although most commercial 
real-time strategy games make use of UDP as a transport, the 
presence of reliability implemented in the application layer pre¬ 
vents any threats from adversaries that drop, or significantly 
delay packets in transmission. As a result, attacks {e.g., [19]) 
that result in denial-of-service for Castle users are not possible 




















































without also affecting legitimate game players. 

6.2 Resilience to application layer attacks 

Highly motivated censors may perform actions outside the 
realm of standard network traffic analysis and manipulation. 
We consider censors that may interact with the game server 
using custom game clients in order to reveal the identities of 
Castle users. Specifically, censors may connect to game server 
lobbies to identify Castle games and join these games to learn 
the IPs of participating clients. For these cases, Castle provides 
several defenses based on features available in the cover game. 

If the cover game supports the use of password-protected 
multi-player games, Castle proxies may host games using high- 
entropy passwords distributed using, for example, a BridgeDB- 
like mechanism [40]. Therefore censors without knowledge of 
the password are unable to join Castle games and learn the IP 
addresses of Castle clients. 

If the cover does not support the use of password-protected 
games, a Castle proxy may incorporate either (or, both) of the 
following defenses: (1) The proxy may use standard game maps 
rather than custom-made Castle game maps. This allows Castle 
instances to blend in with legitimate game instances, making it 
harder for the censor to identify which games to join. However, 
this comes at the cost of lower throughput since there are typ¬ 
ically fewer units in standard game maps. (2) The proxy may 
still use a BridgeDB-like mechanism for password distribution 
and require that any Castle client makes the moves correspond¬ 
ing to the supplied password in order to receive proxying ser¬ 
vices. In the event that a client does not supply this password 
within some period of time, the Castle proxy may continue 
playing the game using a standard AI. Therefore, even a cen¬ 
sor that is able to enter games is unable to distinguish between 
Castle games and legitimate player games. 

6.3 Avoiding covert channel pitfalls 

Geddes et al. highlight three key mismatches between covert 
channels and cover traffic which make these look-like-something 
circumvention tools detectable to external observers [19]. Here 
we discuss how Castle avoids each of these three mismatches. 

The architecture mismatch. Games provide agility in terms 
of architecture that few other channels provide. They often op¬ 
erate in client-server mode on publisher-hosted game servers 
and in peer-to-peer mode in direct-connect multi-player games. 
Our proxying approach can operate in whichever mode is the 
dominant, and in the presence of blocking can even shift {e.g., 
from client-server to peer-to-peer). 

The channel mismatch. While game data is typically com¬ 
municated over a UDP channel, it is not resilient to packet loss 
like other UDP-based channels (e.g., VoIP), thus clients come 
with the ability to handle packet losses and retransmissions. 
Further, they also guarantee in-order delivery and processing 
of sent data. This makes it especially useful as a covert channel 
for proxied TCP connections which require reliable transmis¬ 
sion. Therefore, attacks that allow the censor to drop traffic to 
levels which are tolerable to legitimate players (but intolerable 
to Castle users) are not possible. 

The content mismatch. Content mismatches arise when 
the content being embedded in the covert channel changes the 
flow-level features of the channel. Since the flow-level features 
of real-time strategy games are strongly dependent on many pa¬ 
rameters (identified above), they are highly variable. We have 


shown that Castle, under every configuration, generates traffic 
that is well within this variance. 


7. Performance Evaluation 

Without any game-specific modifications, Castle offers per¬ 
formance amenable to transfer of textual data (e.g., tweets, e- 
mail, news articles).^ 

Since each real-time strategy game has a limit on the number 
of objects that can be selected for a single command, the data 
rate obtained by Castle is game dependent. For example, 0 A.D. 
allows the selection of up to 200 units for a single command, 

E?“iog ('“) 

giving us an average of ^' ^ooxS ' ~ bytes per command. 

On the other hand. Aeons has no limits on the number of units 
that may be selected for a single command but allows only < 
435 objects to be placed within a single screen - giving us an 
average of ~ 39 bytes per command. 

Throughput is also dependent on the time required by the 
desktop automation tool to perform the actions required to is¬ 
sue a command (i.e., click each unit to be selected and click 
the target coordinate). We found that on average, issuing a 
single command required between 300-350 ms. With no de¬ 
lays between the issue of each command, this allows ~ 3 com¬ 
mands/second. 

In Figure 7, we see the effect of Castle’s parameters on it’s 
performance when implemented over 0 A.D. Specifically, Fig¬ 
ure 7a shows the effect of increasing the maximum number of 
buildings selected in a single command and Figure 7b demon¬ 
strates the effect of decreasing the command rate. At a config¬ 
uration where Castle may select up to 200 buildings in a sin¬ 
gle command and issues commands with no delays in between, 
Castle implemented over 0 A.D. is able to provide a data rate 
of ~ 190 Bytes per second - requiring about 52 seconds for the 
transfer of a short 10KB text news article. 

7.1 Game-specific enhancements for Castle 

In this section, we show that the performance of Castle can 
be improved significantly through simple game-specific tweaks. 
To be able to observe the impact of these game-specific modi¬ 
fications, Aeons was used as the channel for vanilla Castle and 
Castle with Aeons-specific modifications. The game-specific 
modifications were introduced and implemented for Castle in 
just under three hours by an undergraduate researcher. 

The low throughput of Castle over Aeons was because Aeons 
had larger units than 0 A.D., thereby allowing players to place 
only 435 units within a single screen (as opposed to 1,600 for 
0 A.D.). As a result, the throughput of vanilla Castle was only 
~ 38 bytes/command (i.e., < 130 bytes/second) at best - i.e., 
with the maximum command rate of AutoHotkey and selection 
of up to 435 units/command. 

A quick investigation into the Aeons replay mode and save- 
game files revealed that even the selection of a single unit was 
communicated over the network and logged by other players. 
We exploit this fact by creating a set of 2“ units (256 in our 
case) and mapping each unit to an m — bit value (i.e., a byte). 
We then sequentially transfer the data byte-by-byte via select¬ 
ing the unit corresponding to the byte to be encoded. 

^The success of the voices feeds [41] during the Arab Spring 
shows that in some situations textual data is enough to get in¬ 
formation out. 



8. Discussion 
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Figure 7: Throughput of Castle implemented over 0 A.D. under 
various configurations 



Figure 8: Throughput of Castle (with and without enhance¬ 
ments) implemented over closed-source Aeons 


This encoding allowed AutoFlotkey to issue commands at a 
significantly faster rate than before (a command was now just 
a single mouse click, as opposed to up to 435 key presses and 
clicks). At AutoHotkey’s fastest mouse click rate and ra = 8, 
this encoding achieved a throughput of up to 3KByte/second. 
However, in order to more closely mimic the command rate 
and traffic generafed by a human player, we add a delay of be¬ 
tween 2 and 3 ms per command. In Figure 8, we show the 
effect of this game-specific modification on the throughput of 
Castle. From the same figure, we can also observe the effect 
of varying the total number of units with vanilla Castle and the 
Aeons-specific version of Castle. We see that increasing n re¬ 
sults in a linearly increasing throughput for vanilla Castle, and a 
logarithmically increasing throughput for Aeons-specific Cas¬ 
tle. However, because the cross-over point of these functions 
is higher than the game allows, Aeons-specific Castle always 
achieves better throughput for Aeons. 


In this section, we discuss Castle in the context of its abil¬ 
ity to provide deniability to users of the system and provide 
extensibility that can tip the scales in favor of circumvention 
developers. We also discuss various methods to improve the 
throughput of Castle and compare the design methodology of 
Castle with the most similar related work - Rook and Free- 
Wave. 

Deniability and ease of distribution. One of the advan¬ 
tages of Castle is that the covert channel is largely implemented 
with off-the-shelf software components with only a few hun¬ 
dred lines of code dedicated to encoding data and desktop au¬ 
tomation scripting. Desktop automation tools, are already com¬ 
monly used by gamers and the game, game-specific mods, etc., 
are generally widespread enough to warrant little suspicion from 
censors (e.g., Aeons is installed by millions of users). 

Castle’s small core size also makes it easy to distribute through 
hard to block methods - e.g., via the text body in emails and 
even through instant messaging services. 

Extensibility of Castle. Castle’s strength comes from the ease 
with which it can be ported to new games. As an example, it 
took a bright undergrad less than 6 hours to complete a basic 
port of Castle over a very popular closed-source real-time strat¬ 
egy game. Due to the availability of game-specific hacks and 
reverse engineering guides in popular gaming forums [42^4], 
completing game-specific enhancements in order to improve 
the data rate of Castle, as described in Section 7.1, required 
only an additional 3 hours. 

Although individual game titles do not present a high collat¬ 
eral damage, in the event that they are blocked, Castle presents 
a simple way to convert each of them into an ephemeral and ef¬ 
fective covert channel, with little development overhead. This 
ability, along with the fact that every newly released title is a 
potential covert channel, makes Castle particularly useful in the 
arms-race that censors and developers are currently engaged in. 
In particular, it is the first censorship circumvention tool to pro¬ 
vide an asymmetry in favor of the developer (i.e., creating a 
new channel is significantly less expensive than detecting the 
channel). 

Improving Castle throughput. In addition to making game- 
specific modifications, Castle presents many opportunities to 
increase throughput of the system. 

• Parallel requests: Since most modem real-time strategy 
games allow up to eight players to participate in a single 
multi-player game, it is possible for one censored user to 
decode content responses from up to seven proxies in par¬ 
allel - achieving up to lx downstream throughput. This 
is particularly useful in the context of web data, where re¬ 
quests are easy to parallelize. 

• Content compression. Castle proxies may improve perfor¬ 
mance by compressing requested content before encoding. 
In the context of web data, the proxies may also pre-render 
and compress content before sending them to the receiver 
{e.g., as was done by the Opera mobile browser [45]). 

• Trade-off throughput and detectability. Depending on the 
level of surveillance in a given region Castle may expose an 
option to allow users to trade off throughput vs. detectabil¬ 
ity of the system (e.g., by increasing the rate of clicks in the 
automation tool). 

Comparison of design methodology. In terms of design 


























methodology, Rook and FreeWave are most similar to Castle. 
Like Castle, Rook also uses games as the cover protocol, al¬ 
though the goals of Rook and Castle are quite different. The 
primary goal of Castle is adaptability - Castle is loosely cou¬ 
pled to the underlying game, enabling developers to quickly 
adapt Castle to many games. Rook is focused on stegono- 
graphic security; even if the adversary is able to join the same 
gaming session as two Rook users, the attacker will still not be 
able to determine whether the other players are using Rook to 
surreptitiously transmit data. As a result. Rook aims for secu¬ 
rity against a very powerful adversary, but has over lOOx lower 
bandwidth than Castle. 

FreeWave and Castle are similar in that they both work above 
the application layer, mimicking user input to the application, 
rather than the application itself (FreeWave uses a modem to 
encode data into audio transmissions over VoIP clients). Simi¬ 
lar to Castle, FreeWave also allows extensibility to other similar 
applications. However, there are significantly more real-time 
strategy games available for use as cover protocols than there 
are VoIP clients. 

To the best of our knowledge, Castle is the only covert chan¬ 
nel that (1) appears to satisfy all the covert channel design prin¬ 
ciples laid out by Geddes, et al [19], (2) provides extensibility 
to hundreds of applications (games), potentially with only a few 
hours effort for each, and (3) is evaluated for security at the ap¬ 
plication and network layer. 

9. Conclusions 

In this paper we have presented Castle, a general approach 
for creating covert channels using real-time strategy games as 
a cover for covert communications. We demonstrate our ap¬ 
proach by prototyping on two different games with minimal 
additional development overhead and show its resilience to a 
network adversary. We argue that the popularity, availability, 
and generic functionalities of modern games make them an 
effective circumvention tool in the arms-race against censors. 
Specifically, our results show that Castle is: 

• Secure: Castle is resistant to attacks such as IP/port fil¬ 
tering and deep-packet inspection since it actually executes 
the game application. More complicated and expensive at¬ 
tacks such as traffic analysis attacks are avoided due to the 
high variability of standard game flows. 

• Usable: Even without any game-specific modifications, 
Castle is able to provide throughput sufficient for transfer 
of textual data. Additional enhancements make it suitable 
for use as a web proxy. 

• Extensible: Incorporating new closed-source games as covert 
channels for Castle requires only a few hours of developer 
time - including the addition of title-specific enhancements 
for increased throughput. 

The results presented in this work motivates two independent 
future research directions. First, extending our work to differ¬ 
ent classes of games which may enable higher throughput rates 
{e.g., racing games, first person shooters). Second, integrating 
the Castle approach into platforms to make it usable to users 
e.g., via a Web browser plugin or integration with the suite of 
Tor Pluggable Transports [15]. 

Code and data release: To ensure reproducibility of our re¬ 
sults and ease comparative evaluation, our implementation of 


Castle is available at https: //github. com/bridgar/Castl 
e-Covert-Channel. 

Video demonstration: A video demonstration of Castle im¬ 
plemented over 0 A.D. is available at https://www.youtub 
e.com/watch?v=zpjZJuvMhDE. 
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